…pache#62686)

Issue Number: close #0

Problem Summary: When a string column contains extremely long values,
running
ANALYZE on it can consume excessive memory and may even OOM the BE. This
PR
introduces an inline per-row guard that short-circuits stats collection
for any
string column whose rows exceed
`Config.statistics_max_string_column_length`
(default 1024 bytes).

The guard is injected into every statistics-collection SQL template
(FULL_ANALYZE_TEMPLATE, LINEAR_ANALYZE_TEMPLATE, DUJ1_ANALYZE_TEMPLATE,
HMS full/sample) as a `NoneMovableFunction`:

assert_true(col IS NULL OR LENGTH(col) <= N,
'ANALYZE_SKIP_LONG_STRING_COLUMN')
    AS __lc

When any row violates the predicate, `assert_true` triggers a controlled
error
carrying the `ANALYZE_SKIP_LONG_STRING_COLUMN` marker.
`BaseAnalysisTask`
walks the exception cause chain for this marker and, when detected,
converts
the failure into a FINISHED task with a skip message so users see why
the
column was dropped (via SHOW ANALYZE and via OK-packet info for sync
analyze).
Other columns in the same job are unaffected.

Setting `statistics_max_string_column_length = 0` disables the guard
entirely
(upstream behavior).

Added FE config `statistics_max_string_column_length` (default 1024).
String
columns whose row byte length exceeds this value are skipped during
ANALYZE
with a visible skip message, instead of risking OOM. Set to 0 to
disable.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>